You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Switches the Triage workflow trigger from pull_request back to pull_request_target so multi-labeler and action-semantic-pull-request can write labels and post a commit status on PRs from forks (e.g. #2845). Under pull_request, GitHub forces GITHUB_TOKEN to read-only for fork PRs, regardless of the workflow's declared permissions:, which is why the labeler check has been failing.
Why this is OK (and reverting #2763 here is acceptable)
#2763 deliberately moved this file to pull_request to clear zizmor's dangerous-triggers audit. That audit's load-bearing concern is future drift — someone later adds a run: step or an unpinned uses:, and the privileged context becomes RCE without anyone noticing.
In our case the practical control is review: every change to this file goes through PR review by maintainers who have write access, and the workflow itself is structurally minimal — no actions/checkout, no run: steps, only SHA-pinned actions that read PR metadata via the GitHub API. None of zizmor's listed vectors (argument injection, env injection, file relinking) have a surface here without one of those building blocks being added, and adding them requires explicit maintainer approval.
The trigger now carries an inline # zizmor: ignore[dangerous-triggers] directive with the reasoning above written directly into the workflow, so the exception is self-documenting and zizmor's audit stays clean. Verified locally: zizmor .github/workflows/triage.yml → No findings to report.
Test plan
Zizmor run passes
On the next fork PR, the Auto-label PR check succeeds and labels are applied
Many online resources suggest that pull_request_target and other dangerous triggers can be used securely by ensuring that the PR's code is not executed, but this is not true: an attacker can often find ways to execute code in the context of the target repository, even if the workflow doesn't explicitly run any code from the PR. Common vectors for this include argument injection (e.g. with xargs), environment injection (e.g. LD_PRELOAD), and local file inclusion (e.g. relinking files to the runner's credentials file or similar).
Okay, so after a brief investigation, it seems the goal of zizmor’s dangerous-triggers audit here is to warn against future drift — i.e. someone later adding a run: step or unpinned uses: and the privileged context silently becoming an RCE surface — rather than flagging the current file as exploitable. In our case that drift can’t land without a maintainer-approved diff, and the workflow today has no checkout, no run:, and only SHA-pinned actions reading PR metadata via the API. Pushed a follow-up that adds an inline # zizmor: ignore[dangerous-triggers] with that reasoning written directly above the trigger so the exception is self-documenting.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Switches the Triage workflow trigger from
pull_requestback topull_request_targetsomulti-labelerandaction-semantic-pull-requestcan write labels and post a commit status on PRs from forks (e.g. #2845). Underpull_request, GitHub forcesGITHUB_TOKENto read-only for fork PRs, regardless of the workflow's declaredpermissions:, which is why the labeler check has been failing.Why this is OK (and reverting #2763 here is acceptable)
#2763 deliberately moved this file to
pull_requestto clear zizmor'sdangerous-triggersaudit. That audit's load-bearing concern is future drift — someone later adds arun:step or an unpinneduses:, and the privileged context becomes RCE without anyone noticing.In our case the practical control is review: every change to this file goes through PR review by maintainers who have write access, and the workflow itself is structurally minimal — no
actions/checkout, norun:steps, only SHA-pinned actions that read PR metadata via the GitHub API. None of zizmor's listed vectors (argument injection, env injection, file relinking) have a surface here without one of those building blocks being added, and adding them requires explicit maintainer approval.The trigger now carries an inline
# zizmor: ignore[dangerous-triggers]directive with the reasoning above written directly into the workflow, so the exception is self-documenting and zizmor's audit stays clean. Verified locally:zizmor .github/workflows/triage.yml→No findings to report.Test plan
Auto-label PRcheck succeeds and labels are applied